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A survey of air-traffic-management researchers, representing a broad range of automation applications, was 
conducted to document trajectory-predictor requirements for future decision-support systems. Results indicated that 
the researchers were unable to articulate a basic set of trajectory-prediction requirements for their automation 
concepts. Survey responses showed the need to establish a process to help developers determine the trajectory- 
predictor-performance requirements for their concepts. Two methods for determining trajectory-predictor 
requirements are introduced. A fast-time simulation method is discussed that captures the sensitivity of a concept to 
the performance of its trajectory-prediction capability. A characterization method is proposed to provide quicker, yet 
less precise results, based on analysis and simulation to characterize the trajectory-prediction errors associated with 
key modeling options for a specific concept. Concept developers can then identify the relative sizes of errors 
associated with key modeling options, and qualitatively determine which options lead to significant errors. The 
characterization method is demonstrated for a case study involving future airport surface traffic management 
automation. Of the top four sources of error, results indicated that the error associated with accelerations to and from 
turn speeds was unacceptable, the error associated with the turn path model was acceptable, and the error associated 
with taxi-speed estimation was of concern and needed a higher fidelity concept simulation to obtain a more precise 
result. 

Thi s pap e r d es crib es an initial s tudy toward s th e d e t e rmination of r e quir e m e nt s for futur e traj e ctory pr e diction 
capabiliti e s. Th e first obj e ctiv e was to docum e nt n e w r e quir e m e nts for traj e ctory - pr e diction. R e quir e m e nts w e r e 
coll e ct e d through int e rvi e ws — of d e cision - support conc e pt d e v e lop e rs. Whil e surv e y r e spons e s id e ntifi e d 
r e quir e m e nts for th e d e cision - support - tool conc e pts consid e r e d, f e w p e rformanc e r e quir e m e nts sp e cific to th e 
s upporting - traj e ctory pr e diction w e r e surfae e d. - R e sults d e monstrat e d - th e- n ee d - - for - a -se e e nd - r ese ar - ch ob je ct i y o : -- to 
es tabli s h a pr - oc ess- to d e t e rmi ne th e traj e ctory pr e dictor p e rformanc e- r e qu i r e m e nt s- fer - hitur e- conc e pt s— Th e- out - l - in e 
of s uch a proc ess wa s d e v e lop e d. Con s id e ration for alt e rnativ e approach es s ugg es t s th e n ee d for fa s t tim e s imulation 
analy s i s at a l e v e l of fid e lity n e c ess ary to ad e quat e ly captur e th e s e n s itivity of a conc e pt to th e p e rformanc e of it s 
traj e ctory pr e diction capability. An alt e rnativ e option, th e charact e rization of traj e ctory pr e diction e rror s , may 
provid e a s impl e r, quick e r, but l ess pr e ci se analy s i s m e thod. Th e m e thod i s ba se d on analy s i s and s impl e s imulation 
to charact e riz e th e traj e ctory pr e diction e rror s a ss ociat e d with k e y mod e ling option s for a s p e cific conc e pt. Thi s 
provid es pr e liminary ord e r of magnitud e r es ult s to h e lp conc e pt d e v e lop e r s id e ntify th e r e lativ e s iz es of e rror s 
associat e d with traj e ctory mod e ling options and qualitativ e ly d e t e rmin e which options l e ad to significant e rrors. To 
d e monstrat e th e m e thod, charact e rization analysis was appli e d to a surfac e op e rations cas e bas e d on NASA’s futur e 
surfac e- automation r e s e arch focus ar e a. R e sults indicat e d that th e e rror associat e d with acc e l e rations to and from 
turn sp ee ds was unacc e ptabl e , the e rror associat e d with th e turn path mod e l was acceptabl e , and th e e rror associat e d 
with taxi s p ee d wa s of conc e rn and n ee d e d a high e r Fid e lity conc e pt simulation to obtain a mor e pr e ci se r es ult. 

A. Introduction 

One objective of the Next-Generation Air Transportation System (NextGen) transformation is to transition to 
trajectory-based operations (TBO) for managing the National Airspace System (NAS). [1] TBO uses four- 
dimensional trajectories to manage aircraft. TBO will require improved trajectory prediction capability and a 
seamless interface among disparate trajectory predictors (TPs) serving multiple types of airborne and ground-based 
automation systems. [2] A key step to improving trajectory prediction is to understand the current capabilities of and 
future requirements for trajectory predictors. Answering the question of how to determine future TP requirements 
for NextGen is difficult but essential. In particular, it is important to match the requirements of the TP to the needs 
of the automation system it supports. If a specific TP is unable to meet the performance requirements of its client 
automation system, then the success of the system depends on at least one of two actions: either the TP and 
supporting infrastructure (e.g., source of track, intent, and wind forecast data, etc.) must be improved, or the 
operational concept for the automation system must be adapted to work with the TP performance provided. It is 
desirable to not only establish the minimum TP requirements for the "client" automation application, but also to 
build a TP that meets those requirements while minimizing complexity and avoiding unnecessary effort and cost. 
Recent works investigating the current state of TP requirements and capabilities include a workshop with MITRE 
Corporation and NASA and a survey of TP requirements conducted by a team of TP experts from (but not limited 
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to) the Eurocontrol research labs, FAA, and NASA. These works are described in more detail in the Background 
section of this paper. 

There are two primary objectives of the work described in this paper. The first is to document requirements for 
new TP capabilities to be developed at NASA to support the NextGen vision. Requirements were collected through 
the interview of automation concept developers, based on the API 6 structure. The interview included questions 
about functional requirements (for example, modeling, inputs and outputs, coordinate system, and prediction 
horizon) and non-functional or performance requirements (which include prediction accuracy and speed of 
response). The goal was to determine opportunities for common TP requirements. A secondary goal of this objective 
was to encourage trajectory predictor clients to think about requirements at the level of the predictor, not just at the 
higher-level of the automation system. The first objective assessed what the researchers knew about the TP 
requirements for their concepts. Based on those findings, the second objective explored methods for determining TP 
requirements for the goal of helping researchers define TP requirements for automation systems of the future. 

The paper begins with more detail about the previous efforts that relate to this work. Following is a description 
of the TP requirements survey then followed by a discussion of the survey results. The results lead into a section that 
explores the process for determining quantitative TP performance requirements. The method of TP error 
characterization is then introduced to show a direct relationship between some key TP functional and non-functional 
(performance) requirements. The purpose of this method is to identify the characteristics that need to be modeled at 
a minimum to achieve a desired TP performance level. An initial application of this analysis to surface operations is 
provided as an example that can be further expanded upon for surface concepts or generalized to other applications. 
The results will contribute toward defining prediction capabilities required for the future air transportation system as 
well as work plans for future trajectory predictor development. It is also expected that this process will facilitate the 
definitions of quantifiable requirements and performance (accuracy) metrics to be established. 

B. Background 

Prior work has attempted to make progress on the task of understanding current and future trajectory predictor 
requirements. A common objective has been to gather and document the TP requirements and capabilities of 
existing automation systems. The primary purpose has been to identify opportunities for the development and shared 
use of common TP capabilities. Examples of common capabilities of interest include aircraft performance and pilot- 
procedure models, algorithms for modeling flight dynamics, and interfaces between trajectory-based automation 
systems that would enable the synchronization of predicted trajectories across disparate systems. Trajectory 
synchronization is key to the interoperability of automation systems that depend on higher levels of TP accuracy 
such as airborne Flight Management Systems (FMS) and ground-based separation assurance systems for Air Traffic 
Control. 

The first effort was conducted in the form of a two-day workshop (December 1999) involving senior technical 
leads from MITRE Corporation’s Center for Advanced Aviation System Development and NASA. The scope was 
limited to a small set of Air Traffic Management (ATM) automation applications, primarily en route, including the 
Center-TRACON Automation System (CTAS), the User Request and Evaluation Tool (URET), and envisioned 
enhancements to both. The results of the workshop, captured in an annotated briefing, included a side-by-side 
comparison of the major TP capabilities of each application highlighting similarities and differences. The 
comparison also included a summary of the major drivers behind the development of the capabilities. This exercise 
did provide an initial understanding of both the high-level similarities and differences in TP capabilities for these 
applications, as well as some insights regarding how to compare TP requirements and capabilities. However, the 
details were at too high of a level to point to significant opportunities for common capabilities. A major impediment 
was the lack of documentation of the salient details related to each TP. [3] 

The second major effort was conducted under the auspices of the US-Europe ATM R&D Action Plan 16 (AP16) 
for Common Trajectory Prediction Capabilities. AP16 is a team of senior trajectory-prediction experts representing 
the Federal Aviation Administration (FAA), NASA, Eurocontrol research labs, and major industry R&D 
organizations developing air traffic control and airborne (e.g., avionics and airframe) automation systems. The team 
conducted a broader survey requesting details on the trajectory predictor requirements and capabilities (in any form) 
from approximately twenty research and operational organizations. The request introduced the survey and described 
the specific aspects of trajectory prediction for which information was needed. Key technical leads were contacted 
directly through a formal letter of request, email, and follow-up phone calls. After a year of effort, many indicated 
they had nothing to offer. Of the few that did respond with relevant details, the content varied widely from one 
organization to another, the material was inconsistent in what was documented (little comparable overlap), and the 
scope of information was significantly incomplete. 
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Several key conclusions were generated based on feedback from these past efforts and analysis of the limited 
material obtained. First, documentation of this type is a systemic challenge for the community, particularly the 
research labs where the changes in requirements and capabilities can occur quite frequently as research progresses. 
Second, the focus of most automation concept/system developers seems to be limited to higher-level requirements 
for their automation system. Many developers have difficulty determining what their automation concept/system 
specifically requires from its supporting trajectory predictor capabilities. Third, the wide range of approaches taken 
to implement trajectory predictors, for research and operational systems, makes it difficult to understand the 
similarities of (and true differences between) any two predictors. Two key elements are needed to achieve 
significant progress in the development and reuse of trajectory predictor capabilities across the R&D community. 
First is the need for a simple and concise methodology to “standardize” documentation to achieve clear, consistent, 
complete, and cross-comparable trajectory predictor requirements and capabilities. Second is the need for practical 
methods that can generate quantitative TP performance requirements that are comparable across the community. 

Along the way, API 6 developed a generic trajectory predictor structure to provide a common representation of 
trajectory predictors. [4] This generic TP structure was developed in a cooperative effort to resolve conflicts in 
terminology and overcome the challenges of significant architecture differences among TP developers. The common 
structure avoids the debate of what components constitute a TP and where those components belong in a system 
implementation. This provides a basis for identifying common requirements, (performance) metrics, and validation 
methods. Therefore, the structure facilitates the documentation of requirements and capabilities for comparison 
across different TP client automation systems. 


C. TP Requirements Survey 

The survey was conducted through a series of interviews with leading researchers at NASA. The API 6 generic 
TP structure was used to organize the survey and define questions in a general way, independent of any specific 
architecture. Additional question details and examples were motivated by a review of internal documentation 
describing the TP capabilities for a few existing ground-based automation applications. Each interview began with 
questions about the “client” application(s) that require trajectory predictor capabilities, typically decision-support 
automation or a simulation. Next, the interview questions explored the needs of the client applications. In some 
cases, existing TP capabilities were already in use and adequate to support some of the research. In other cases, new 
capabilities were required to support the client applications. 

The questions regarding client needs were organized into four areas based on the four main TP-related processes 
defined in the generic TP structure: preparation, trajectory prediction, trajectory prediction update, and the export 
process. The preparation process included any flight data or parameters required to compute a trajectory. The 
preparation questions asked about this required information along with any inputs to the TP and how the movement 
of the aircraft is modeled. The trajectory prediction process calculates the trajectory using the information from the 
preparation process. The prediction part of the interview investigated the methods used to compute the trajectories. 
The interview then addressed the trajectory prediction update process. During an update, the prediction process is 
triggered to recalculate a trajectory in response to new preparation information. These questions involve how 
frequently a trajectory prediction needs to be updated and the results of the update. Finally, the export process 
addressed the expected content and format of the TP output. The interview concluded with questions regarding the 
desired accuracy of the predicted trajectories. 

The technical leads of five of NASA’s ten Air Traffic Management (ATM) research focus areas were 
interviewed. Each interview represented a separate research area at NASA applicable to the NextGen vision: (1) 
surface operations, (2) super-density operations, (3) separation assurance, (4) traffic flow management, and (5) 
dynamic airspace. The survey responses, which included the interview responses and information from internal 
| documentation, were compiled* and an initial analysis was conducted to identify and resolve areas of ambiguity in 
the responses. Supplementary questions were generated, based on the collected responses, to address requirements 
that had not been considered previously. The responses from each interviewee were analyzed to determine if the 
responses described a requirement for, or capability of, the TP needed to enable their concepts. Once the initial 
analysis was completed for all five interviews, results were reviewed collectively for commonalities among 
| trajectory inputs, outputs, modeling (preparation process), and computation (prediction process) requirements. 

A summary of the survey results is presented here. The goals of the applications and functions reliant on 
trajectory prediction are introduced for each research area. Some common requirements among the systems and 
selected interview responses are then presented. 
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Research Area Applications 


Surface Operations 

The surface operations research area is focused on enabling super-density operations on the surface and 
immediate airspace around an airport. The approach is to develop and evaluate new concepts and algorithms for 
a wide variety of surface automation applications. These applications include taxi planning and surface-traffic 
optimization, taxi-clearance conformance monitoring, conflict detection and resolution, collision avoidance, and 
the mitigation of environmental impacts. Ground-based and flight-deck solutions will be based on the prediction 
and monitoring of 4D trajectories for both departure and arrival traffic on and near the surface. The 4D 
trajectories will describe how the aircraft (and other vehicles) will move along the surface including major 
intersection points and the arrival times for each point. 

The requirements for the TP to support these applications have not yet been defined. The researcher was able 
to provide some general and partial requirements for the TP, but this list was far from complete. The general 
requirements were primarily in the form of prediction time horizon. The horizon requirement for taxi planning is 
30 minutes, 5 min for conformance monitoring and 20 to 30 sec for collision avoidance. While there were no TP 
accuracy performance requirements per se, the researcher felt that a kinetic (force-based) performance model 
would be required. The TP would also require actual and forecasted weather information as an input, such as 
rainfall and icing, along with a model of how weather conditions would affect surface traffic movement. 

Super-Density Operations 

Super-density operations refer to the highest density terminal operations conceived for NextGen. The 
research is currently focused on determining accuracy requirements and understanding the level of performance 
the system needs. Efforts are focused on mitigating weather impact and developing scheduling improvements to 
understand the tradeoffs in different system objectives as a function of uncertainty. Examples of these systems 
objectives are capacity, efficient climb/descent profile, meeting user-specified objectives, and minimizing noise 
and emissions. 

Currently, NASA’s research in super-density operations is not sufficiently mature to determine the 
characteristics of and requirements for supporting automation, let alone supporting TP. One anticipated 
requirement is the need for a prediction of the uncertainty at each point along a predicted trajectory. 

Separation Assurance 

The Center - TRACON Automation System (CTAS) is a decision support tool used for arrival-management 
and separation-assurance research by NASA. CTAS is a set of tools that produce advisories for aircraft in the 
remaining airspace not covered by surface operation or super-density operations, including en-route and less- 
dense terminal areas. Some advisories include the earliest arrival times for aircraft entering the TRACON, an 
arrival metering schedule, the assignment and sequence of arrivals to a runway, trajectory modifications to meet 
scheduled times, conflict detection and resolution, and which aircraft would benefit from deviating from their 
filed flight plan routes by using shorter, more direct, conflict-free routes. 

The trajectory prediction engine, called the Trajectory Synthesizer (TS), is at the core of CTAS. The TS 
predicts a 4D trajectory for each aircraft from its current position to its destination (or next air traffic control 
facility) based on inputs from higher-level algorithms for route analysis and profile selection. CTAS trajectory 
prediction is initiated by any of the route-generation and profile-selection processes in CTAS. 

Similar to surface operations, requirements for trajectory prediction are not explicitly defined for separation 
assurance. Following the definition of the concept, the uncertainty values of the computed trajectories must be 
below the vertical and lateral separation criteria of the aircraft. The prediction accuracy must be high enough to 
maintain the performance of the automation system. [5] The TP must be fast enough to compute trajectories in 
the “required time allotted” (within the 12 second processing cycle for CTAS) and respond to controller requests 
in a controller-acceptable amount of time. 

Traffic Flow Management 

Traffic flow management manages traffic flows on a national and regional level. The Future Air Traffic 
Management Concept Evaluation Tool (FACET) is a research platform used to study traffic flow management 
concepts. [8] FACET provides a flexible simulation environment for development and evaluation of advanced 
air traffic management (ATM) concepts. It can be used to determine sector loads and complexity of the airspace. 
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It allows rapid prototyping of new ATM concepts in the en-route airspace. These concepts include airborne self- 
separation, dynamic density predictions for airspace redesign and aircraft rerouting, and integrating space launch 
vehicles into the NAS. Each of these concepts is reliant on trajectory prediction. Currently, FACET as a tool is 
not being further developed but the algorithms within FACET are being improved to make the current state of 
FACET more useful. Some near term goals of the project include developing weather translation, aggregate 
flow models, optimization work, and airspace complexity. 

Dynamic Airspace 

Dynamic airspace applies to terminal through en-route airspace. An automation system has not been designed 
specifically for dynamic airspace configuration. Instead, an existing automation system with trajectory 
prediction capability already developed by NASA will be used. The chosen system will be modified to calculate 
the maximum capacity of a given airspace. The capacity is the number of aircraft in the airspace at a given time. 
The system will determine ways to change airspace configurations that will allow for larger capacity. 

An example of a new airspace configuration consists of tubes of airways within the airspace that would be 
similar to highways on the ground. Consequently, one role of the TP would be to assist in the tube design. The 
accuracy of the TP and the anticipated trajectory error would dictate the best size of the tubes. The predicted 
trajectories will also be used to determine the complexity of the given airspace. Based on the complexity of the 
airspace, the limit on capacity can be determined. Complexity is defined by mathematical formulas. The 
complexity would be calculated given the expected incoming trajectories and their uncertainty bounds. 
Therefore, the dynamic airspace concept requires both the prediction of specific 4D trajectories as well as the 
uncertainty of those predictions. Another demi-requirement resulting from these applications include allowing 
the user to input error bounds into the TP for the nominal prediction. 

Selected Interview Responses 

Tables 1 and 2 summarize of the responses to a functional requirement and non-functional requirement 
question, respectively, collected during the interviews. 


Table 1: How will turns be modeled? 


Surface Operations 

Modeling details of the future trajectoiy predictor are unknown. 

Super-Density 

Operations 

Circular-arc turns of constant radius: preferred for Required Navigation Performance routes 
Model with roll and speed dynamics: Vectors 

Separation Assurance 

All turns are circular arcs of constant radius 

Traffic Flow 
Management 

Turns are modeled as instantaneous 

Dynamic Airspace 

Not important 

Priority: get a trajectory predictor up and running quickly to support algorithm development 


Table 2: Have any performance requirements been defined? 


Surface Operations 

No. Trajectory must be very accurate for monitoring and conflict detection and resolution 

Super-Density 

Operations 

No. Requirements are being investigated but none are currently defined. 

Separation Assurance 

No. Need as accurate as possible with uncertainty below separation standards (5 nmi, 1 000 ft) 

Traffic Flow 
Management 

No. Trajectory error is too high; any error reduction would be an improvement 

Dynamic Airspace 

No. Requirements to be a function of the airspace complexity or performance boundaries of the 
trajectory predictor 


Common Inputs and Outputs 

The interview responses were compared to identify common requirements. Common requirements were 
found in the input and output requirements which are listed in Table 3. 
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Table 3: Common Requirements for Trajectory Prediction 


Common Requirements 

Input 

Initial aircraft state, Intent information, Aircraft performance model, Pilot procedure model, Airspace definition, forecasted 
winds or temperature 

Output 

Predicted 4D trajectory, Trajectory uncertainty 


D. Discussion of Survey Results 

The objective of the survey was to document trajectory predictor requirements for future automation systems, 
but few requirements actually resulted from the survey. For all of the research areas interviewed, requirements on 
future trajectory prediction had not been adequately considered. The actual responses provided information at more 
of a system level. As a result, the collected interview responses fit into three categories: an incomplete requirement 
for a future trajectory predictor, an existing requirement or capability for a legacy system, or an ambiguous response 
that doesn’t clearly fit into either of the previous categories, but which may be a requirement for the trajectory 
predictor or the automation system. 

An example of an incomplete requirement for a future predictor is one taken from the interview of the Surface 
Operations research area that states that the TP must be very numerically efficient since it will have to modify and 
recalculate the trajectory quickly. This is roughly a performance requirement for the predictor, but it is missing the 
performance requirements for specific Surface Operations functions as well as knowledge of the dependency of the 
Surface Operations functions on TP performance. The second category of interview responses is also a result of 
undefined future requirements. A requirement or capability of a legacy system was often cited in the interviews 
when the future requirement was unknown. This can be seen in the Traffic Flow Management research area. The 
responses refer to current capabilities or requirements of FACET, the legacy system being used. Though a need for 
better trajectory prediction performance for future operations as compared to current operations is apparent, the 
requirements for the future system in this area are still being regarded in terms of the legacy system. 

A common response to a question about requirements on the expected output of the trajectory predictor was a 
requirement to output the uncertainty of the predicted trajectories. This response fits in the third category of the 
interview responses, because it is unclear if the response is truly a requirement of the trajectory predictor or the 
automation system the trajectory predictor supports. Prediction errors must be defined by the client automation. A 
trajectory predictor computes a trajectory based on inputs and set algorithms and models. From the perspective of 
the predictor there is no uncertainty in its prediction since it has successfully computed the trajectory. The 
requirements of the operational concept will determine what is considered an error. Therefore, the function of 
determining the uncertainty of the prediction should be implemented outside of the trajectory predictor. However, an 
uncertainty that can be computed by the predictor is any uncertainty in its computations. One can require a predictor 
to know the uncertainty in its calculations and provide that information as output from the TP. Details of the type of 
uncertainty the client requires would be needed to clarify if this function is a requirement for the trajectory predictor 
or the automation system. This category of responses implies that the concept requirements are poorly defined. The 
client needs comprehensive requirements on the concept before being able to define the trajectory predictor 
requirements. Otherwise, the resulting trajectory predictor requirements will also be poorly defined and difficult to 
interpret when developing the prediction algorithms and functions. 

Very few requirements were defined for the functionality or performance of the predictor in any of the research 
areas. Samples from the interview contained in Tables 1 and 2 support this finding and highlight other significant 
results. Table 1 shows the responses to the question of how turning along a trajectory needs to be modeled in the 
future trajectory predictor. Note the variation in the responses; some describe the turn model used in a legacy 
system while others have not determined what is required. None of the responses, with the exception of the 
response from Super-Density Operations, gives requirements for turn modeling for future trajectory prediction. For 
Surface Operations, for example, the turn modeling required for a future trajectory predictor is unknown. Turn 
modeling is also a functional requirement decision that may have a significant impact on trajectory predictor 
performance under TBO and deserves serious consideration. Figure 1 illustrates three ways to model a turn along a 
trajectory: an instantaneous turn, a constant radius turn at a constant speed, and a turn with roll-in, roll-out and speed 
dynamics modeled. The figure shows the differences in path distance corresponding to the choice of turn model. 
These differences result in three different trajectory predictions at different levels of prediction accuracy. Therefore, 
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the performance of the trajectory predictor is affected by this modeling decision, and a requirement on the turn 
model of the trajectory predictor may be needed to meet the prediction requirements needed to support the client 
automation. The different turn models described in Table 1 show that the functional requirements for trajectory 
prediction may vary greatly with the client application. In addition lacking a complete set of requirements, the 
designers of the client applications studied here do not yet have a complete understanding of what is required to 
operate in the NextGen system. The Separation Assurance and Super-Density Operations research areas are both 
operating in the terminal area. For Separation Assurance turns are modeled as circular arcs of constant radius. Super- 
Density Operations would need additional turn models that consider roll and speed dynamics. Both are operating in 
the same domain but seem to have contradicting requirements for trajectory prediction. 



Instantaneous Turn 

Turn with 

roll-in/roll-out 

dynamics 


Figure 1: Effects of Turn Modeling on Path Distance 


Table 2 is the response to the question “Have any performance requirements have been defined for the future 
trajectory predictor?” In all areas interviewed the answer was “No.” None of the researchers knew what 
performance was required for their future system. The responses they did provide did not provide enough 
information to form a requirement for the trajectory predictor. For example, for surface operations the trajectory 
must be very accurate for monitoring conformance and conflict detection and resolution, but this accuracy could not 
be quantified. In many cases, the researchers were not sure how to determine trajectory predictor requirements and 
requested help with this task. 

In the absence of requirements for future systems, one way to make progress is to look at the current state of the 
art. In particular, this research looked for common requirements in the research areas interviewed. These common 
requirements may represent some minimum or initial requirements for future trajectory predictors. Table 3 contains 
a list of the only requirements consistent in all five of the interviews: the input and output to the trajectory predictor. 
The fact that input and output were the only areas found with consistent requirements demonstrates the small 
amount of progress made by clients knowing and understanding the uniqueness of their trajectory predictor 
requirements. However, the general nature of the input and output requirements provided is little more than self- 
evident and provides no specifics that can be used to identify similarities or differences in the TP requirements for 
each area. Consistent details relating to modeling and performance requirements would provide insight to what is 
needed for the future. 

In summary, few trajectory predictor requirements were identified from the survey. Of those obtained, most were 
incomplete requirements for trajectory prediction or legacy capabilities of a legacy system. Few requirements were 
defined for the performance or functionality of the predictor. Often the requirements were confused with the higher- 
level automation system requirements. Some researchers were not sure how they would determine the requirements 
needed for their future concepts and requested help. Given that the original objective of the research could not be 
reached, an alternative approach was pursued. 


E. Process for Determining Requirements 

While the results included a few functional requirements, the distinct lack of performance requirements is 
problematic. The performance requirements for a system, if defined, drive a great portion of the functional 
requirements. Alternatively, if functional decisions precede the definition of performance needs, the performance of 
the system may be limited unnecessarily. Once the client automation system or concept has defined the performance 
requirements for its supporting TP, the definition of functional requirements is a much simpler task. Overall, the 
results of the survey showed that the researchers need help determining requirements for their trajectory predictor. 
This finding is consistent with the prior API 6 survey and shows that clients of trajectory prediction in general need 
help with TP requirements. 
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The results also implied that researchers were attempting to design TPs without having well-defined trajectory 
prediction requirements. The risks involved with this behavior are major. One major consequence is a TP that 
doesn’t meet the needs of the client or operational concept. In this case, the researcher can attempt to change the TP 
to meet the client’s requirements or, alternatively, change the corresponding operational concept. Altering the TP 
will involve additional effort and costs along with delay to implementation. Even with the additional effort it may 
not be possible to meet the desired performance with the existing system architecture of the TP. The researcher may 
then opt to change the operational concept but that may be met with some resistance from the client and the original 
need for the predictor is still left unfulfilled. Consequently, the second objective of this research was identified: 
establish a process to determine trajectory predictor requirements, particularly performance requirements, for future 
automation systems. 

The method of finding TP requirements proposed in this paper begins with these two steps: 1) obtain the client’s 
performance requirements for the automation system, and 2) determine the sensitivity of the automation system 
performance to the TP performance. Before requirements for the TP performance can be defined the client must 
have clear and comprehensive performance requirements for the concept or automation system. The critical TP 
performance requirements are directly dependent on the unique performance requirements of the automation system 
itself. The choice of performance metrics is the responsibility of the client. This information must be provided by 
the client before seeking help to define performance. Knowledge of the automation system performance 
requirements is important to ensure the trajectory predictor performance meets the needs of the concept but does not 
unnecessarily exceed those requirements. This way the client can avoid additional effort and costs. 

Another prerequisite to determining performance requirements is to understand the relationship between the 
performance of an automation system and its supporting trajectory predictor. There are two parts of this relationship 
of interest: the sensitivity of the automation system performance to the TP performance, and the sensitivity of the 
TP performance to key functional components of the predictor (including inputs to the predictor and models and 
algorithms used for prediction). It is in determining this sensitivity where this research can aid TP clients. 

There are a number of possible approaches to determine the sensitivity discussed above. This work considered an 
analytical approach, a real-world experiment, a human-in-the-loop (HITL) simulation, and a fast-time simulation. 
An analytical approach, while having the potential to provide the fastest results, faces significant challenges here. TP 
performance is multi-dimensional, time-varying, and non-linear. This is not the best form for an analytical 
approach. It would be very difficult, if not nearly impossible, to derive an analytical expression representing a wide 
range of conditions and error possibilities for the trajectory-predictor performance. A real-world experiment to study 
the sensitivity would require personnel and equipment over an extended period of time. The costs associated with 
this type of experiment would be very high, data collection would be limited, and only a limited number of cases 
could be studied. A HITL simulation would introduce greater experimental control, but there would still be 
significant costs associated with personnel that would limit the number of cases significantly. While a fast-time 
simulation approach would be missing the human element, it could be much more cost and time-efficient than the 
real-world experiment or HITL simulation. Setting the sensitivity analysis aside, however, the HITL simulation 
approach would provide an excellent way to address step one above: to help the clients of TP (automation 
system/concept developers) determine the performance requirements for their automation system. 

A fast-time simulation approach is advocated to determine the sensitivity. With this approach, a modeling and 
simulation platform would be used to evaluate the effects of several factors on TP performance and their impact on 
the automation system performance. With such a platform, the performance of an automation system/concept could 
be modeled and evaluated as a function of TP modeling assumptions under a wide range of operational conditions, 
aircraft performance errors, and input uncertainty. This approach would serve as the basis for establishing 
relationships between TP performance and automation system performance. Development and application of this 
approach to a specific automation system/concept may take a year if not longer. An alternate method is needed to 
start progress towards determining TP performance requirements now while the fast-time simulation concept is 
being further developed. The characterization method presented in the following paragraphs provides a way 
forward. 


F. Characterization of TP Errors 

The characterization method described in the paper can help trajectory predictor clients begin to approximate 
performance requirements by providing a relatively quick and easy way to study the sensitivity of TP performance 
to critical dynamics involved in its application. The objective of the characterization is to identify potentially critical 
dynamics that the TP may need to model in order to meet the requirements for the client automation system 
performance. The characterization analysis begins with identifying dynamics that are likely to be crucial to the 
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performance of the TP. The critical dynamics will vary depending on the domain in which the TP is applied. The 
next step is to define metrics and test conditions that will excite problems or behaviors of interest in these dynamics. 
With these metrics defined, compute trajectories with the corresponding test conditions with and without the 
dynamics modeled. Finally, present the results — the sensitivity of the trajectories to the dynamics — to the client. 
The client can use these results to judge the impact of errors on the automation system caused by modeling (or not 
modeling) the dynamics. The characterization method is applied to the surface operations research area as an 
example. 

A challenge for surface operations is computing the estimated time of arrival (ETA) of the aircraft at different 
places of interest along its taxi route. Trajectories are used to compute ETAs for managing aircraft crossing a 
runway, managing the usage of intersections, and determining the location of an aircraft along its taxi route at any 
given time. Better ETA predictions are needed for the cases mentioned above for scheduling, conflict avoidance, 
detection, and resolution purposes. The objective of the characterization method applied to surface operations is to 
evaluate the effects of modeling decisions for trajectory prediction on the total surface trajectory durations. The 
modeling decisions include determining what dynamics should be modeled of the trajectory predictor to improve its 
predictions. Four types of dynamics are modeled in this example of the characterization method. The modeling 
decisions related to these four dynamics are illustrated in Figure 2 which is a representation of a taxi route. 


Accelerate Taxi at Turn speed ^ taxi speed? 

to taxi constant Decelerate/Accelerate 



The different color regions represent different modeling techniques for surface trajectory prediction along the route. 
The first dynamic to consider in the figure is acceleration. Specifically, how will the trajectory predictor model how 
the aircraft will accelerate to the desired taxi speed from a stop or decelerate to a stop? The next dynamic is the taxi 
speed. Will the aircraft travel at a constant or variable taxi speed? There are a few decisions involved for aircraft 
approaching a turn. Will the turn speed be different from the taxi speed? If so, will the predictor model deceleration 
to and acceleration from the turn speed? Will the path of the turn be a point where an instantaneous turn occurs or a 
constant radius arc? 

Given a specified taxi trajectory, the duration was computed with and without each of the four dynamics 
modeled. Three example taxi routes were chosen from the map of the Dallas-Fort Worth International Airport. As 
can be seen in Figure 3, each route varied in total distance and number of turns to be traversed. The figure also 
shows the nominal taxi time for each route which is the computed total trajectory duration for a baseline reference. 


r ifl^ir 





Taxi 

Route 

Taxi 

Distance 

(nmi) 

Taxi 

Time 

(sec) 

Taxi 

Speed 

(kts) 

Number 
of Turns 

Sum of 1 
Turns 
(deg) 


A 

1.35 

325 

15 

5 

400 


B 

0,81 

194 

15 

3 

180 ; 


C 

0.46 

110 

15 

2 

80 




Figure 3: Route Description 
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In the surface operations example, instantaneous acceleration and constant acceleration were the two methods 
considered for computing trajectories. The duration of the trajectory was computed both ways. The value of constant 
acceleration used was 2 ft/s 2 . A constant taxi speed with a nominal value of 15 knots was used. To study the impact 
of the predicted taxi speed on the trajectory duration, trajectories were also computed with off-nominal values of 
taxi speed from +/- 1 up to +/- 5 knots from the nominal value. The trajectory time was also computed for 
trajectories modeled with instantaneous turns or constant-radius turns and deceleration into and acceleration out of 
the turns to characterize the turn dynamics. The total trajectory times computed for each condition were compared 
to a chosen baseline to determine the maximum prediction error resulting from the speed model, acceleration model 
to and from a stop, the turn path model, and the model for decelerating to turn speed when entering a turn then 
accelerating back to the taxi speed at the exit. The details of the conditions used to calculate the trajectory time and 
the description of each baseline case are shown in Table 4. 


Table 4: Characterization Test Conditions 


Dynamic 

tested 

Description of test conditions 

Speed 

Constant taxi speed, instantaneous turns, instantaneous acceleration 

Baseline 

taxi speed of 15 knots , instantaneous turns, instantaneous acceleration 

Acceleration 
to/from stop 

Constant taxi speed, instantaneous turns, constant acceleration 

Baseline 

Constant taxi speed, instantaneous turns, instantaneous acceleration 

Turn model 

Constant taxi speed (no slowing for turns), turn modeled with curve segment 
length, instantaneous acceleration 

Baseline 

Constant taxi speed, instantaneous turns, instantaneous acceleration 

Deceleration 
to turn speed 

Constant taxi speed, turn modeled with curve segment length and constant turn 
speed (less than taxi speed), constant acceleration, and deceleration to turn speed 

Baseline 

Constant taxi speed, instantaneous turns, instantaneous acceleration 


Table 5 shows the maximum prediction error in seconds resulting from each of the four dynamics. This table 
demonstrates the effect of the modeling decision for each dynamic on the total surface trajectory duration. 


Table 5: Trajectory Prediction Errors 


Route 

Max Prediction Error (sec) 

Speed 

error 

(+/- 3 kts) 

Acceleration 
to/from stop 

Turn 

Model 

Deceleration 
to Turn Speed 

A 

92 

18 

18 

129 

B 

55 

18 

7 

73 

C 

34 

18 

3 

47 


For route A, there is a 92-second error resulting from three knots of deviation from the predicted (nominal) taxi 
speed. This accounts for 28% of the total trajectory duration. The resultant prediction error from modeling versus 
not modeling the deceleration to a slower turn speed is 129 seconds, which is 40% of the total trajectory time. The 
errors caused by not modeling accelerations to and from stop and the decision to model an instantaneous versus a 
constant-radius turn each are six percent of the total trajectory duration. From this table, the client can see the error 
contribution from each of the dynamics. In this case, one would conclude that, at the minimum, the trajectory 
predictor for surface operations must have accurate models of the taxi speeds, turning speeds, and the transition 
between them for each aircraft to avoid critical prediction errors. 

G. Conclusion 

The objective to survey and document trajectory predictor requirements for the future air transportation system 
could not be completed. NASA researchers were able to articulate few trajectory predictor requirements. The survey 
uncovered that little progress has been made in the knowledge and understanding of the trajectory predictor 
requirements needed to support future trajectory-based automation systems. Some of the researchers were unsure 
how to define future requirements and asked for help. As a result, the second objective of this research was formed 
to define a process for determining future trajectory predictor requirements. While a modeling and simulation 
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approach may provide a way to determine the trajectory predictor performance needed to support future concepts, 
such an approach will need to be developed and tested. In the meantime, the characterization method introduced in 
this paper provides a relatively quick and simple way to begin defining trajectory predictor performance 
requirements. Airport surface operations were analyzed to demonstrate this method for providing a relatively fast, 
first-order-of-magnitude understanding of the impact of modeling factors on the predictor performance. Results 
indicate that the error associated with accelerations to and from turn speeds was unacceptable, the error associated 
with the turn path model was acceptable, and the error associated with taxi speed was of concern and needed a 
higher-fidelity concept simulation to obtain a more precise result. The characterization allowed the client to 
approximate the trajectory predictor accuracy needs based on consideration of typical errors that will occur due to 
modeling dynamics and expert judgment on the impact of those errors on client performance. 

The next steps for this research include enhancing the characterization of the surface applications by a 
comprehensive analysis of recorded surface trajectory data and identifying and characterizing other important 
dynamics for surface-trajectory prediction. The characterization will also be applied to other clients. Another 
objective is to develop and use the fast-time modeling and simulation approach presented in this paper to study the 
sensitivity of the trajectory predictor performance to key components of the predictor. 
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